Use the async Always Encrypted key store APIs on async execution paths - #4585

Async command execution now resolves Always Encrypted key material through
the asynchronous key store provider APIs, so a provider that performs network
I/O (for example Azure Key Vault) no longer blocks a thread pool thread for the
duration of every column encryption key decryption, column master key signature
verification, and enclave package generation.

Utility layer (Phase 4):
* SqlSecurityUtility gains DecryptSymmetricKeyAsync, GetKeyFromLocalProvidersAsync
  and VerifyColumnMasterKeySignatureAsync.
* SqlSymmetricKeyCache gains GetKeyAsync, which never holds the cache lock across
  provider I/O.

Call sites (Phase 5):
* sp_describe_parameter_encryption result parsing is now shared by the sync and
  async paths. Signature verifications and key decryptions are recorded while
  parsing and executed afterwards, so no key store call is made while the reader
  is still positioned mid-stream.
* The two callback-based describe-parameter-encryption continuations collapse
  into a single async method, preserving the existing thread pool hand-off and
  error/cancellation semantics.
* EnclaveDelegate and SqlCommand gain async enclave package generation, used by
  the async execution path.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

GetParameterEncryptionDataReader returned void with an out Task and did
nothing but dispatch asynchronous work, so its name gave no hint that the
caller was receiving a pending operation. The name was inherited from main,
where it was actively misleading: the overload without the Async suffix was
the one that continued from a pending network write, while the overload with
the suffix was the one used when that write had already completed.

Rename the dispatcher to GetParameterEncryptionDataReaderAsync and have it
return the task directly instead of through an out parameter, and rename the
async body to ConsumeDescribeParameterEncryptionResultsAsync, which describes
what it actually does. Both names now carry the Async suffix and both return
a task.

Also make the Task.Run rationale precise. It is not merely a convenience: the
body issues blocking TDS reads before it reaches a suspension point, and
PrepareForTransparentEncryption runs synchronously on the caller's thread
under the async entry points, so awaiting inline would put those reads on the
caller's thread whenever the network write is null or already complete.
Neither continuation this replaced could run inline, since one used Task.Run
and the other used ContinueWith without ExecuteSynchronously.

No behaviour change.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 82aca8ca-2078-4a47-860c-6f6ee78cbb02

Report CreateColumnEncryptionKeyInfo as the throwing member in the
internal null-argument diagnostics. The throws moved into that shared
helper and are now reachable from both the sync and async decrypt
paths, so naming GetDecryptedKeysToBeSentToEnclave was misleading. This
also matches the convention used by EncryptBytePackage and
ComputeQueryStringHash in the same type.

Use TdsEnums.AEAD_AES_256_CBC_HMAC_SHA256 and
SqlClientEncryptionType.Deterministic in the query metadata cache tests
instead of bare literals with explanatory comments.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 82aca8ca-2078-4a47-860c-6f6ee78cbb02

A pass over the async Always Encrypted work looking for correctness,
performance, and consistency problems. The behavioural changes:

Capture the cancellation token on the originating thread. The token lives
in a field so it does not have to be threaded through layers of
callback-driven code that have no use for it, but the Always Encrypted
work is handed to the thread pool and can outlive the cleanup
continuation that resets that field. Reading it late could silently
observe CancellationToken.None. It is now read once at the two
synchronous capture points and passed on as an explicit parameter.

Make the symmetric key cache insert non-cancellable. Cancelling between
a successful decrypt and the cache insert threw away a key that had
already cost a key store round trip, so the next caller paid for it
again.

Drop a dead serverName parameter from both GetDecryptedKeysToBeSentToEnclave
overloads, and give the result list a capacity hint.

The rest is allocation and clarity work: lazily allocate the pending key
operation lists and hand them out as IReadOnlyList, walk them by index so
the interface enumerator is not boxed, and make IsEnclaveEnabled an
explicit field on ColumnMasterKeySignatureVerification rather than a
hard-coded true that only happens to be correct because of where the call
sits.

Also documents three decisions that look like missed optimisations but
are not. The Task.Run in GetParameterEncryptionDataReaderAsync cannot be
awaited inline because the task it waits on is completed by the SNI
network callback, so an inline continuation would run blocking TDS reads
on a callback thread. Column encryption key decryption stays sequential
because distinct cipher metadata entries often share a key, and
GetKeyAsync does not hold its gate across provider I/O, so parallel
misses for the same key would each issue their own key store call.
Sequential decryption lets the first result warm the cache.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 82aca8ca-2078-4a47-860c-6f6ee78cbb02

CompleteCachedQueryMetadataAsync treated every exception from the column
encryption key load as evidence that the cached metadata was stale, and
invalidated the entry. Cancellation is not evidence of anything of the
sort, so cancelling an execution threw away a perfectly good cache entry
and made the next caller pay for another describe parameter encryption
round trip.

Cancellation now propagates without touching the cache. This failure
mode cannot arise on the synchronous path, so only the asynchronous
overload handles it and the two stay otherwise identical.

The existing cancellation test only asserted that the operation threw,
which is why this went unnoticed. It now also asserts that the entry
survives and that a subsequent uncancelled load still succeeds, and it
fails without the fix.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 82aca8ca-2078-4a47-860c-6f6ee78cbb02

Gate async loads per cache key, recheck after waiting, and remove idle gates. Preserve independent cancellation, different-key concurrency, and sync/async publication behavior.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 038a9db2-f9a4-45c3-a80a-73cfe8a3bc9f

Observe caller cancellation before rethrowing the last CEK candidate error or wrapping a CMK verification exception. Cover immediate and deferred failures with single and multiple candidates.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 038a9db2-f9a4-45c3-a80a-73cfe8a3bc9f

Keep synchronous provider blocking off the thread pool and let the test orchestration own its release without a competing provider watchdog.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 038a9db2-f9a4-45c3-a80a-73cfe8a3bc9f

Serialize provider invocation with the existing semaphore, releasing it before awaiting returned tasks. Cover synchronous and base-async owners plus cancellation while waiting without blocking completed-key publication.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 038a9db2-f9a4-45c3-a80a-73cfe8a3bc9f